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Abstract 


The Centralized Conferencing Manipulation Protocol (CCMP) document 
(RFC 6503) defines a way for a client to discover a conference 
control server that supports CCMP. However, it does not define a way 
for a client involved in a conference to determine if the conference 
focus supports CCMP. This information would allow a CCMP-enabled 
client that joins a conference using SIP to also register for the 
Centralized Conferencing (XCON) conference event package and take 
advantage of CCMP operations on the conference. 


This document describes two mechanisms, depending upon the need of 
the User Agent (UA), to address the above limitation. The first 
mechanism uses the Call-Info header field, and the second mechanism 
defines a new value for the "purpose" header field parameter in the 
<service-uris> element in the SIP conferencing event package. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Not all documents 


approved by the IESG are a candidate for any level of Internet 
Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7082. 
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1. Introduction 


RFC 5239 [RFC5239] defines a framework for Centralized Conferencing 
(XCON), which allows participants to exchange media in a centralized 


unicast conference. The framework also outlines a set of 
conferencing protocols for building advanced conferencing 
applications. 


The Centralized Conferencing Manipulation Protocol (CCMP) [RFC6503] 
allows authenticated and authorized users to create, manipulate, and 
delete conference objects. Operations on conferences include adding 
and removing participants and changing their roles, as well as adding 
and removing media streams and associated end points. 
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CCMP defines a way for an XCON-aware client to discover whether a 
conference control server supports CCMP. However, it does not define 
a way for a SIP client involved in a conference to determine if the 
conference focus [RFC4353] supports CCMP. Knowing that a focus 
supports CCMP would allow a SIP client (that is also XCON aware) that 
joins a conference using SIP-based conferencing [RFC4579] to also 
register for the XCON conference event package [RFC6502] and take 
advantage of CCMP operations on the conference. 


This document describes two options to address the above limitation, 
depending on the need of the User Agent (UA). The first option uses 
the Call-Info [RFC3261] header, which is suitable for application 
servers that need to discover if a UA supports CCMP. The second 
option defines a new value for the "purpose" header field parameter 
in the <service-uris> element in the SIP conferencing event package 
[RFC4575] that is suitable for a UA that would typically subscribe to 
the conference event package. 


Appendix A has a brief description of other options that we 
considered as possible solutions. Those other options were not 
selected, however, because the options described in this document 
better address the problem we are trying to solve. 


1.1. Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 


2. Solutions 


This section defines two mechanisms that can be used by a SIP UA to 
discover whether the conference that a client has joined, per the SIP 
signaling procedures defined in [RFC4579], supports CCMP. 
Specifically, the mechanisms allow the client to know that the URI 
representing the conference focus, as defined in [RFC4579], is an 
XCON-URI as defined in [RFC6501]. 


2.1. Call-Info 


This approach uses the Call-Info header in various requests and 
responses. 


The Call-Info header consists of two parts: a URI and a "purpose" 
header field parameter. The URI provides the XCON-URI of the 
conference focus, and a new value for the "purpose" header field 
parameter indicates that the conference focus supports CCMP. 
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While the XCON-URI by itself should be enough to indicate that the 
conference focus supports CCMP, the "purpose" header field parameter 
with a value of ’ccmp’ provides an easier way for a UA that does not 
use the conference event package to discover that the conference 
focus supports CCMP, without parsing the URI. 


The Call-Info header, with the XCON-URI and the "purpose" header 
field parameter with the ’ccmp’ value, can be used with any INVITE 
request or response and with a response to an OPTIONS request. 


This approach would be suitable for a UA, e.g., an application server 
that acts as a Back-to-Back User Agent (B2BUA), that is interested in 
discovering that a conference focus supports CCMP but does not use 
the XCON conference event package [RFC6502]. In this case, the 
application could use the OPTIONS request and discover CCMP support 
from the response. 


This approach would also be suitable for a conference focus that 
initiates an INVITE request to a SIP UA to add a participant toa 
conference, as it would allow the conference focus to indicate that 
it supports CCMP with the INVITE request sent to the UA. 


The advantage of this approach is the ability to discover that a 
conference focus supports CCMP, without subscribing to the XCON event 
package [RFC6502]. The disadvantage is the need, in some cases, for 
an extra request, i.e., an additional OPTIONS request, to discover 
that a conference focus supports CCMP. 


2.2. Service URI Purpose 


This approach defines an additional URI ’purpose’ of ’ccmp’ 
associated with a <service-uris> element in the SIP conferencing 
event package. The XCON-URI for the conference is included in the 
‘uri’ element, per the following example: 


<service-uris> 
<entry> 
<uri>XCON:confl@example.com</uri> 
<purpose>ccmp</purpose> 
</entry> 
</service-uris> 


The advantage of this approach is that it uses an existing mechanism 
for extending the <purpose> field of the <service-uris> element in 
the conferencing event package [RFC4353]. The disadvantage is that 
it requires the client to subscribe to the conference event package. 
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This approach would be suitable for a SIP UA that would typically 
subscribe to the conference event package. Knowing that a conference 
supports CCMP allows a SIP UA that is XCON aware to make use of the 
CCMP operations and allows it to subscribe to the XCON event package 
[RFC6502] to get additional information related to the conference. 


3. Overall Process 


CCMP capability is discovered using the two methods described in 
Section 2. The order in which the two methods are tried depends on 
whether an implementation subscribes to the conference event package 
by default. 


A UA implementation that subscribes to the conference event package 
can examine the conference description to see if a URI with 
<purpose>ccmp</purpose> is specified (Section 2.2). An 
implementation that does not subscribe to the conference event 
package can perform an OPTIONS query when connecting to the 
conference server. UAs MUST NOT attempt both methods with the same 
server. 


Conference servers MUST reflect the same information using both 
discovery channels. A server MUST indicate CCMP support through the 
conference event package if and only if it indicates support through 
the Call-Info header in OPTIONS responses. This prevents the need 
for UAs to try both methods. 


4. Security Considerations 
This document defines no new headers or data elements; it reuses 
existing headers and data elements. CCMP already allows a client the 
ability to discover if a conference server supports CCMP, using a DNS 


mechanism as defined in [RFC6503] Section 12.4. 


Thus, the solution options defined in this document do not introduce 
any new security threats. 
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5. IANA Considerations 
5.1. Call-Info Purpose Registration 
This specification adds a new predefined value "ccmp" for the 
"purpose" header field parameter of the Call-Info header field. This 
modifies the registry header field parameters and parameter values by 
adding this RFC as a reference to the line for header field 
"Call-Info" and parameter name "purpose": 
Header Field: Call-Info 
Parameter Name: purpose 
Predefined Values: yes 
Reference: [RFC3261] [RFC5367] [RFC6910] [RFC6993] [RFC7082] 
5.2. URI Purpose Registration 
This specification adds a new predefined value "ccmp" to the "URI 


Purposes" subregistry, which defines XML elements to be encoded in 
the conference event package [RFC4575]. 


This modifies the registry as follows: 
Value: ccmp 


Description: The URI can be used to indicate that the conference 
focus supports CCMP. 


Reference: [RFC7082] 
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Appendix A. Other Approaches Considered 


The following two options were considered as possible solutions but 
were not selected because the options described in this document 
better address the problem we are trying to solve. 


A.1. Feature Tag 


This approach defines a feature parameter ’ccmp’ to indicate that a 
SIP dialog belongs to a conference that supports CCMP. The use of 
feature parameters in Contact header fields to describe the 
characteristics and capabilities of a UA is described in the User 
Agent Capabilities document [RFC3840]. 


The conference focus behavior regarding the handling of the ’ccmp’ 
feature is the same as the behavior for the handling of the ’isfocus’ 
feature parameter. In session establishment, a conference focus MUST 
include the ’/ccmp’ feature parameter in the Contact header field 
unless the conference focus wishes to hide the fact that it isa 
conference focus. 


The advantages of this approach are a one-step discovery of the 
conference focus and its support for the ’ccmp’ feature and the fact 
that it can be used in response to an OPTIONS request, and that it 
enables the discovery of the ’ccmp’ capability by any network element 
that does not need the conference event package. The disadvantage is 
the definition of a new feature parameter. 


A.2. Conference URI Purpose 


This approach defines an additional URI ’purpose’ of ’ccmp’ 
associated with a ’conf-uris’ element in the SIP conferencing event 
package. 


ccmp: Indicates that the conference focus represented by this URI 
supports ‘comp’; this in turn allows a client to use CCMP to 
manipulate the conference. This URI MUST be an XCON-URI as 
defined in the XCON data model specification [RFC6501]. 


<conf-uris> 
<entry> 
<uri>XCON:confl@example.com</uri> 
<display-text>whatever</display-text> 
<purpose>ccmp</purpose> 
</entry> 
</conf-uris> 
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The advantage of the SIP conference event package options is the use 
of an existing mechanism for extending the <purpose> field of the 


<service-uris> or <conf-uris> elements. The disadvantage is the 
requirement that the client register for the conference event 
package. 
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